Add first class component cache by reeganviljoen · Pull Request #2126 · ViewComponent/view_component

reeganviljoen · 2024-10-08T20:00:40Z

closes #234

What are you trying to accomplish?

Add experimental fragment caching for ViewComponent that is true to the ViewComponent ethos, namely:

caching remains component-local (no hidden global state required to work)
caching that can easily be debugged with standard debugging tools like breakpoints

What approach did you choose and why?

I chose to add an opt-in caching API:

ViewComponent::Cacheable + a cache_on macro that declares which instance methods contribute to the cache key
cache keys include component identity + template identity (variant/format) + declared dependencies (via ActiveSupport::Cache.expand_cache_key) + a component digest
the component digest invalidates cached output when the component’s source changes (Ruby file, templates, i18n sidecars) and when rendered child ViewComponents change
template dependency extraction compiles templates to Ruby and uses Prism to find render dependencies
- ERB uses stdlib ERB::Compiler (no Temple)
- Slim/Haml are loaded lazily and only when those handlers are used

Anything you want to highlight for special attention from reviewers?

This is intentionally opt-in (global opt-in via require "view_component/fragment_caching" or per-component include ViewComponent::Cacheable)
Added integration coverage proving parent cache invalidates when a child component template changes
cache_on supports private methods and uses Rails cache key expansion for dependency values
Known limitation: partial/layout string dependencies are not currently included in the digest (workaround: bump RAILS_CACHE_ID/RAILS_APP_VERSION on deploy)
Follow-ups can extend the API (procs, conditionals/options, broader dependency coverage)

reeganviljoen · 2024-10-15T19:32:51Z

@joelhawksley @Spone @camertron I would appreciate any thoughts on this.

joelhawksley

@reeganviljoen THANK YOU for taking a crack at building something functional to address the long-overdue need for caching in ViewComponent.

To be honest with you, I have not used caching in Rails nearly enough to feel like I can properly assess this PR in terms of how it would integrate with the existing mental model of caching in Rails. I'm happy to learn that context, but I won't have the space to do so for at least a couple of weeks.

@Spone @boardfish have y'all done much with Rails' caching? @reeganviljoen if you know of anyone else in the community who would be a good reviewer here, I'd be happy to have them.

reeganviljoen · 2024-10-16T04:28:05Z

@reeganviljoen THANK YOU for taking a crack at building something functional to address the long-overdue need for caching in ViewComponent.

To be honest with you, I have not used caching in Rails nearly enough to feel like I can properly assess this PR in terms of how it would integrate with the existing mental model of caching in Rails. I'm happy to learn that context, but I won't have the space to do so for at least a couple of weeks.

@Spone @boardfish have y'all done much with Rails' caching? @reeganviljoen if you know of anyone else in the community who would be a good reviewer here, I'd be happy to have them.

@joelhawksley I really aprreciate the honesty, I will see if I can find anyone with cache experience to take a crack at reviewing this ❤️

boardfish · 2024-10-16T08:09:41Z

@joelhawksley Afraid it's not something I've really interacted with directly until now, sorry! I'd be coming from a similar place. Great to see @reeganviljoen working at it, though ✨

lib/view_component/base.rb

lib/view_component/cacheable.rb

JWShuff

Reegan, really excited to see this. I'm going to take a shot at adapting our gem spec suite to your fork and open a PR at your fork with those specs by way of giving us a place to start that gives us the most cache functionality we can get.

JWShuff · 2024-11-14T18:06:40Z

lib/view_component/base.rb

    include ViewComponent::Slotable
    include ViewComponent::Translatable
    include ViewComponent::WithContentHelper
+    include ViewComponent::Cacheable


Suggestion, nitpick and nonblocking: Can we slide this in alphabetically above? I'd think it'd be ~ line 32

JWShuff · 2024-11-14T19:05:53Z

lib/view_component/experimentally_cacheable.rb

+      __vc_cache_dependencies.push(*args)
+    end
+
+    def inherited(child)


We took this for a spin in a few cases of our cached partials and view components that we are familiar with and largely it works for the base cases. This is working to correctly bust a cached VC when it changes or things in the render path 'above' (partials or VCs) it change.

What we aren't seeing is when a VC renders another VC or partial as a child that downstream changes of the cached VC pick up changes and handle it. I'm going to fork your branch and offer some test cases based on an approach we use in the vc fragment caching gem (what we're currently solving this with)

Effectively we want some way for a child partial or VC change (in either the .rb or template) to bust the cached parent.

@JWShuff like touch: true in rails ?

also big thanks for testing it, I can look at adding the touch true thing later this week

@reeganviljoen I'd expect us to test this with changes to child partials.

JWShuff

Added a hypothetical approach to an integration test for the behavior.

JWShuff · 2024-11-14T22:03:20Z

test/sandbox/test/rendering_test.rb

@reeganviljoen I am not a git-wizard, much to my eternal shame, but I set up a fork and adjusted the spec approach here to use the integration examples/controllers to assert the behavior. Feel free to take, leave, or otherwise.

JWShuff#1

There's a wider challenge around partial/template digesting, and on a quiet day I'll port our spec suite over to the VC style and get it implemented so we have all the permutations we know of that need to cache appropriately.

reeganviljoen · 2024-11-19T20:19:14Z

@JWShuff I investigated a few of your suggestions, added a few, thanks, and others I am struggling with
luckily I think these aren't required for the initial feature and are more nice to haves that can be implemented in another pr(child cache busting)

reeganviljoen · 2024-11-19T20:19:55Z

@joelhawksley with a live use case tested how do you feel about this now

…or potential adoption

…nstead of custom implementation.

Co-authored-by: Joel Hawksley <joelhawksley@github.com>

reeganviljoen · 2026-02-12T12:36:45Z

@joelhawksley I also added a benchmark for use to have an idea of the gain/overheads of this

ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
       non_cacheable    54.354k i/100ms
      cacheable_miss   168.000 i/100ms
       cacheable_hit     4.108k i/100ms
Calculating -------------------------------------
       non_cacheable    548.026k (± 1.5%) i/s    (1.82 μs/i) -     10.980M in  20.039446s
      cacheable_miss      1.609k (± 9.6%) i/s  (621.47 μs/i) -     31.920k in  20.053582s
       cacheable_hit     40.632k (± 5.5%) i/s   (24.61 μs/i) -    809.276k in  20.018553s

Comparison:
       non_cacheable:   548025.7 i/s
       cacheable_hit:    40631.9 i/s - 13.49x  slower
      cacheable_miss:     1609.1 i/s - 340.58x  slower

reeganviljoen · 2026-02-12T13:34:03Z

After a few refactors to improve the benchmark numbers it now looks a lot better

ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
       non_cacheable    51.748k i/100ms
      cacheable_miss    41.394k i/100ms
       cacheable_hit    39.364k i/100ms
Calculating -------------------------------------
       non_cacheable    558.656k (± 2.3%) i/s    (1.79 μs/i) -     11.178M in  20.019916s
      cacheable_miss    491.207k (± 2.2%) i/s    (2.04 μs/i) -      9.852M in  20.067487s
       cacheable_hit    396.384k (± 4.7%) i/s    (2.52 μs/i) -      7.912M in  20.036403s

Comparison:
       non_cacheable:   558656.4 i/s
      cacheable_miss:   491206.7 i/s - 1.14x  slower
       cacheable_hit:   396383.8 i/s - 1.41x  slower

…mnce

reeganviljoen · 2026-02-12T13:45:35Z

and finnaly I realised the reason the cache benchmarks were worse is because in casses where the coomponent is not expensive to render cache will most likely be too expensive therefore I added more complexitiy to the benchmark components and these are the results

ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
       non_cacheable   181.000 i/100ms
      cacheable_miss   180.000 i/100ms
       cacheable_hit    30.238k i/100ms
Calculating -------------------------------------
       non_cacheable      1.868k (± 2.5%) i/s  (535.35 μs/i) -     37.467k in  20.071934s
      cacheable_miss      1.825k (± 2.4%) i/s  (547.84 μs/i) -     36.540k in  20.030874s
       cacheable_hit    297.514k (± 4.7%) i/s    (3.36 μs/i) -      5.957M in  20.081678s

Comparison:
       cacheable_hit:   297513.6 i/s
       non_cacheable:     1867.9 i/s - 159.27x  slower
      cacheable_miss:     1825.4 i/s - 162.99x  slower

reeganviljoen · 2026-02-13T13:13:11Z

@joelhawksley im not sure if thd primer failure is related but everything I feel is done, I would appreciate a review when ever you can

reeganviljoen changed the title ~~add component controlled cache~~ Add First class component cache Oct 8, 2024

reeganviljoen changed the title ~~Add First class component cache~~ Add first class component cache Oct 8, 2024

reeganviljoen requested a review from joelhawksley October 8, 2024 20:03

reeganviljoen force-pushed the rv_add_component_caching branch from 7544079 to 7533a9c Compare October 10, 2024 15:21

joelhawksley reviewed Oct 15, 2024

View reviewed changes

mikodagatan reviewed Oct 16, 2024

View reviewed changes